Internet Engineering Task Force (IETF) S. Josefsson 


Request for Comments: 7468 SJD AB 
Category: Standards Track S. Leonard 
ISSN: 2070-1721 Penango, Inc. 

April 2015 


Textual Encodings of PKIX, PKCS, and CMS Structures 


Abstract 


This document describes and discusses the textual encodings of the 
Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography 
Standards (PKCS), and Cryptographic Message Syntax (CMS). The 
textual encodings are well-known, are implemented by several 
applications and libraries, and are widely deployed. This document 
articulates the de facto rules by which existing implementations 
operate and defines them so that future implementations can 
interoperate. 


Status of This Memo 
This is an Internet Standards Track document. 
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Internet Standards is available in Section 2 of RFC 5741. 
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http://www.rfc-editor.org/info/rfc7468. 
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1. Introduction 


Several security-related standards used on the Internet define ASN.1 
data formats that are normally encoded using the Basic Encoding Rules 
(BER) or Distinguished Encoding Rules (DER) [X.690], which are 
binary, octet-oriented encodings. This document is about the textual 
encodings of the following formats: 


1. Certificates, Certificate Revocation Lists (CRLs), and Subject 
Public Key Info structures in the Internet X.509 Public Key 
Infrastructure Certificate and Certificate Revocation List (CRL) 
Profile [RFC5280]. 

2. PKCS #10: Certification Request Syntax [RFC2986]. 

3. PKCS #7: Cryptographic Message Syntax [RFC2315]. 


4. Cryptographic Message Syntax [RFC5652]. 
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5. PKCS #8: Private-Key Information Syntax [RFC5208], renamed to One 
Asymmetric Key in Asymmetric Key Package [RFC5958], and Encrypted 
Private-Key Information Syntax in the same documents. 


6. Attribute Certificates in An Internet Attribute Certificate 
Profile for Authorization [RFC5755]. 


A disadvantage of a binary data format is that it cannot be 
interchanged in textual transports, such as email or text documents. 
One advantage with text-based encodings is that they are easy to 
modify using common text editors; for example, a user may concatenate 
several certificates to form a certificate chain with copy-and-paste 
operations. 


The tradition within the RFC series can be traced back to Privacy- 
Enhanced Mail (PEM) [RFC1421], based on a proposal by Marshall Rose 
in Message Encapsulation [RFC934]. Originally called "PEM 
encapsulation mechanism", "encapsulated PEM message", or (arguably) 
"PEM printable encoding", today the format is sometimes referred to 
as "PEM encoding". Variations include OpenPGP ASCII armor [RFC4880] 
and OpenSSH key file format [RFC4716]. 


For reasons that basically boil down to non-coordination or 
inattention, many PKIX, PKCS, and CMS libraries implement a text- 
based encoding that is similar to -- but not identical with -- PEM 
encoding. This document specifies the textual encoding format, 
articulates the de facto rules that most implementations operate by, 
and provides recommendations that will promote interoperability going 
forward. This document also provides common nomenclature for syntax 
elements, reflecting the evolution of this de facto standard format. 
Peter Gutmann's "X.509 Style Guide" [X.509SG] contains a section 
"base64 Encoding" that describes the formats and contains suggestions 
similar to what is in this document. All figures are real, 
functional examples, with key lengths and inner contents chosen to be 
as small as practicable. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in RFC 
2119 [RFC2119]. 


2. General Considerations 


Textual encoding begins with a line comprising "----- BEGIN ", a 
label, and "----- ", and ends with a line comprising "----- END ", a 
label, and "----- ". Between these lines, or "encapsulation 
boundaries", are base64-encoded data according to Section 4 of 
[RFC4648]. (PEM [RFC1421] referred to this data as the "encapsulated 
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text portion".) Data before the encapsulation boundaries are 
permitted, and parsers MUST NOT malfunction when processing such 
data. Furthermore, parsers SHOULD ignore whitespace and other non- 
base64 characters and MUST handle different newline conventions. 


The type of data encoded is labeled depending on the type label in 
the "esscec BEGIN " line (pre-encapsulation boundary). For example, 
the line may be "----- BEGIN CERTIFICATE----- " to indicate that the 
content is a PKIX certificate (see further below). Generators MUST 
put the same label on the "----- END " line (post-encapsulation 
boundary) as the corresponding "----- BEGIN " line. Labels are 
formally case-sensitive, uppercase, and comprised of zero or more 
characters; they do not contain consecutive spaces or hyphen-minuses, 
nor do they contain spaces or hyphen-minuses at either end.  Parsers 
MAY disregard the label in the post-encapsulation boundary instead of 
signaling an error if there is a label mismatch: some extant 
implementations require the labels to match; others do not. 


There is exactly one space character (SP) separating the "BEGIN" or 
"END" from the label. There are exactly five hyphen-minus (also 
known as dash) characters ("-") on both ends of the encapsulation 
boundaries, no more, no less. 


The label type implies that the encoded data follows the specified 
syntax.  Parsers MUST handle non-conforming data gracefully. 
However, not all parsers or generators prior to this document behave 
consistently. A conforming parser MAY interpret the contents as 
another label type but ought to be aware of the security implications 
discussed in the Security Considerations section. The labels 
described in this document identify container formats that are not 
Specific to any particular cryptographic algorithm, a property 
consistent with algorithm agility. These formats use the ASN.1 
AlgorithmIdentifier structure as described in Section 4.1.1.2 of 
[RFC5280]. 


Unlike legacy PEM encoding [RFC1421], OpenPGP ASCII armor, and the 
OpenSSH key file format, textual encoding does *not* define or permit 
headers to be encoded alongside the data. Empty space can appear 
between the pre-encapsulation boundary and the base64, but generators 


SHOULD NOT emit such any such spacing. (The provision for this empty 
area is a throwback to PEM, which defined an "encapsulated header 
portion".) 


Implementers need to be aware that extant parsers diverge 
considerably on the handling of whitespace. In this document, 
"whitespace" means any character or series of characters that 
represent horizontal or vertical space in typography. In US-ASCII, 
whitespace means HT (0x09), VT (0x0B), FF (0xOC), SP (0x20), CR 
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A); 
F. 


"blank" means HT and SP; lines are divided 

The common ABNF production WSP is congruent 
The ABNF 
cific to US-ASCII. As these textual encodings can 
ferent systems as well as on long-term archival 

as paper or engravings, an implementer ought to 
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or in the middle of the base64-encoded data are 
These observations are codified in Figure 1. 
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ture of whitespace outside of the encapsulation 

ure 2). Such lax parsing may run the risk of 

was not intended to be accepted in the first 

e the text was a snippet or sample). 


p the base64-encoded lines so that each line 

64 characters except for the final line, which 
ainder of the data (within the 64-character line 
MUST NOT emit extraneous whitespace.  Parsers MAY 


[RFC1421]. 


Files MAY contain m 
for example, when a 
instances are order 


izes. These requirements are consistent with PEM 


ultiple textual encoding instances. This is used, 
file contains several certificates. Whether the 
ed or unordered depends on the context. 


3. ABNF 
The ABNF [RFC5234] of the textual encoding is: 
textualmsg = preeb *WSP eol 
*eolWSP 
base64text 
posteb *WSP [eol] 
preeb mo oen BEGIN " label "----- " ; unlike [RFC1421] (A)BNF, 
; eol is not required (but 
posteb eom END " label "----- " ; See [RFC1421], Section 4.4) 
base64char = ALPHA / DIGIT / "4" / "/" 
base64pad = "=" 
base64line = 1*base64char *WSP eol 
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base64finl = *base64char (base64pad *WSP eol base64pad / 
*2base64pad) *WSP eol 
; ...AB-2 <EOL> = <EOL> is not good, but is valid 


base64text = *base64line base64finl 
; we could also use «encbinbody» from RFC 1421, which requires 
; 16 groups of 4 chars, which means exactly 64 chars per 
; line, except the final line, but this is more accurate 


labelchar = $x21-2C / %x2E-7E ; any printable character, 
; except hyphen-minus 
label = [ labelchar *( ["-" / SP] labelchar ) ] ; empty ok 
eol = CRLF / CR / LF 
eolWSP = WSP / CR / LF ; compare with LWSP 
Figure 1: ABNF (Standard) 
laxtextualmsg = *W preeb 
laxbase64text 
posteb *W 
W = WSP / CR / LF / $xOB / %x0C ; whitespace 
laxbase64text = *(W / base64char) [base64pad *W [base64pad *W]] 
Figure 2: ABNF (Lax) 
stricttextualmsg - preeb eol 
strictbase64text 
posteb eol 
strictbase64finl = *15(4base64char) (4base64char / 3base64char 
base64pad / 2base64char 2base64pad) eol 
base64fullline = 64base64char eol 


strictbase64text = *base64fullline strictbase64finl 
Figure 3: ABNF (Strict) 
New implementations SHOULD emit the strict format (Figure 3) 


specified above. The choice of parsing strategy depends on the 
context of use. 
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4. Guide 


For convenience, these figures summarize the structures, encodings, 
and references in the following sections: 


Sec. Label ASN.1 Type Reference Module 
————4---------------------- 4-—--------------------- 4--------- T---------- 
5 CERTIFICATE Certificate [RFC5280] id-pkixl-e 
6 X509 CRL CertificateList [RFC5280] id-pkixl-e 
7 CERTIFICATE REQUEST CertificationRequest [RFC2986] id-pkcs10 
8 PKCS7 ContentInfo [RFC2315] id-pkcs7* 
9 CMS ContentInfo [RFC5652] id-cms2004 
10 PRIVATE KEY PrivateKeyInfo ::- [RFC5208] id-pkcs8 
OneAsymmetricKey [RFC5958] id-aKPV1 
11 ENCRYPTED PRIVATE KEY  EncryptedPrivateKeyInfo [RFC5958] id-aKPV1 
12 ATTRIBUTE CERTIFICATE AttributeCertificate [RFC5755] id-acv2 
13 PUBLIC KEY SubjectPublicKeyInfo [RFC5280] id-pkixl-e 


Figure 4: Convenience Guide 


id-pkixmod OBJECT IDENTIFIER ::= {iso(1) identified-organization (3) 

dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) } 
id-pkixl-e OBJECT IDENTIFIER ::= {id-pkixmod pkixl-explicit (18) } 
id-acv2 OBJECT IDENTIFIER ::= {id-pkixmod mod-attribute-cert-—v2 (61) } 
id-pkcs OBJECT IDENTIFIER ::= {iso(1) member-body(2) us (840) 

rsadsi (113549) pkcs(1)) 
id-pkcs10 OBJECT IDENTIFIER ::= {id-pkcs 10 modules(1) pkcs-10(1)) 
id-pkcs7 OBJECT IDENTIFIER ::= {id-pkcs 7 modules(0) pkcs-7(1))] 
id-pkcs8 OBJECT IDENTIFIER ::= {id-pkcs 8 modules(1) pkcs-8(1))] 
id-sm-mod OBJECT IDENTIFIER ::= {id-pkcs 9 smime(16) modules (0)} 
id-aKPV1 OBJECT IDENTIFIER ::= {id-sm-mod mod-asymmetricKeyPkgV1(50)] 
id-cms2004 OBJECT IDENTIFIER ::= {id-sm-mod cms-—2004 (24) } 
* This OID does not actually appear in PKCS #7 v1.5 [RFC2315]. It 


was defined in the ASN.1 module to PKCS #7 v1.6 [P7v1.6], and has 
been carried forward through PKCS 412 [RFC7292]. 


Figure 5: ASN.1 Module Object Identifier Value Assignments 
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5.  Textual Encoding of Certificates 
5.1. Encoding 


Public-key certificates are encoded using the "CERTIFICATE" label. 
The encoded data MUST be a BER (DER strongly preferred; see 
Appendix B) encoded ASN.1 Certificate structure as described in 
Section 4 of [RFC5280]. 


MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQODAjB9MOswCQYDVOOGEWJCRTEPMAOG 
AlUEChMGR251VExTMSUwIwWYDVQOLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 
aXR5MQ8wDOYDVOOIEwZMZXV2ZWAxJTAjBgNVBAMTHEdudVRMUyBjZXJOaWZpY2FO0 
ZSBhadXRob3JpdHkwHhcNMTEWNTIzMjAzODIxWhcNMTIxMjIyMDcOMTUXxWjB9MOQsw 
COYDVOOGEWJCRTEPMAOGA1UEChMGR251VExTMSUwWIWYDVOQOLExxHbnVUTFMgY2Vy 
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDOYDVOOIEwZMZXV2ZWAxJTAjBgNVBAMTHEdu 
dVRMUyBjZXJOaWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhk jOPQIBBggqhk jOPQMB 
BwNCAARS210jiuNnl4Y2sSALCX3IybqiIJUvxUpj*oNfzngvj/Niyv2394BWnWAX 
uQ4ARTEiywK87WRCWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8bEBTADAOQH/MA8GA1Ud 
DwEB/wQFAwMHBgAwHQYDVROOBBYEFPCOgf6YErt*1KLIkQAPLzB9mTigDMAoGCCqG 
SM4 9BAMCA0NgAMEUCIDGuwD1KPyGthRf 8 8MeyMOcqOF ZD0TbVleF+USAGO4enAiEA 
14wOuDwKQatupc8GftXE2C//4mKANBC6It01gUaTIpo= 


Figure 6: Certificate Example 


Historically, the label "X509 CERTIFICATE" and also less commonly 
"X.509 CERTIFICATE" have been used. Generators conforming to this 
document MUST generate "CERTIFICATE" labels and MUST NOT generate 
"X509 CERTIFICATE" or "X.509 CERTIFICATE" labels. Parsers SHOULD NOT 
treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to 
"CERTIFICATE", but a valid exception may be for backwards 
compatibility (potentially together with a warning). 
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5.2. Explanatory Text 


Many tools are known to emit explanatory text before the BEGIN and 
after the END lines for PKIX certificates, more than any other type. 
If emitted, such text SHOULD be related to the certificate, such as 
providing a textual representation of key data elements in the 
certificate. 


Subject: CN-Atlantis 
Issuer: CN-Atlantis 
Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC 


MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMXETAPBgNVBAMTCEFObGFudGlz 
MB4XDTEyYMDcwOTAZMTAZOFOXDTEZMDcwOTAZMTAZN1owEzERMA8GA1UEAxMIQXRs 
YW50aXMwXDANBgkgqhkiG9w0BAQEFAANLADBIAkEAu+BXot+miabDIHHxt+yquqzqNnh 
Ryn/XtkJIIHVCYtHvIX-S1x5ErgMoHehycpoxbErZmVRAGCq1S2diNmRFZCRtQID 
AQABo4GJMIGGMAwGA1UdEWwEB/wQCMAAwIAYDVROEAQH/BBYwFDAOMAwGCisGAQQB 
gjcCARUDAgeAMBOGA1UdJQOWMBOGCCSGAQUFBwMCBggrBgEFBQCDAzA1BgNVHQEE 
LjJASgBAO jOnSSulHYmnVryHAdywMoRUWEzERMA8GA1UEAxMIOXRsYW50aXOCASow 
COYFKwA4DAhOFAANBAKi6HRBaNEL5ROn56nvfclQNaXiDT174uf*lojzAA4lhVIncO 
ILwpnZlizL4Ml1I9eCSHhVOBHEp2uQdXJB-*td5Byg- 


Figure 7: Certificate Example with Explanatory Text 
5.3. File Extension 


Although textual encodings of PKIX structures can occur anywhere, 
many tools are known to offer an option to output this encoding when 
serializing PKIX structures. To promote interoperability and to 
separate DER encodings from textual encodings, the extension ".crt" 
SHOULD be used for the textual encoding of a certificate. 
Implementations should be aware that in spite of this recommendation, 
many tools still default to encode certificates in this textual 
encoding with the extension ".cer". 


This section does not disturb the official application/pkix-cert 
registration [RFC2585] in any way (which states that "each '.cer' 
file contains exactly one certificate, encoded in DER format"), but 
merely articulates a widespread, de facto alternative. 
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6. Textual Encoding of Certificate Revocation Lists 


Certificate Revocation Lists (CRLs) are encoded using the "X509 CRL" 
label. The encoded data MUST be a BER (DER strongly preferred; see 
Appendix B) encoded ASN.1 CertificateList structure as described in 
Section 5 of [RFC5280]. 


MIIB9DCCAV8CAQEwCwYJKOZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s 
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXNOIE5ldHdvcmsxRjBEBgNVBAST 
PXd3dy52ZXJpc21nbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu 
LEXxJQUIuTFREKGMpOTgxHjACBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm 
MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxlICOgTmVOc2NhcGUxGDAWBgNVBAMU 
D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DOEJARYTcC21tb25Aam9zZWZzc29u 
Lm9yZxcNMDYxMjI3MDgwMjMOWhcNMDcwMjA3MDgwMjM1WjAjMCECECAQNwPfRoWd 
elUNpllhhTgXDTA2MTIyNzAAMDIzNFowCwYJKoZIhvcNAQEFAAGBADOzX-*J2hkcc 
Nbrq1Dn51KL8nXLgPGcHvl1I/lelMNo9tlohGQOxB5HnFUkRPAY82fR6Epor4aHgVy 
bt5ytneKNO9Rn2mPFAiiunta4026CjJOpArojCL1p8TOyyi9Xxvyc/ezaZ98HilyP 
c3DGMNR+oUmS jKZ20jIhAYmeLxaPHfOWR 


Figure 8: CRL Example 


Historically, the label "CRL" has rarely been used. Today, it is not 
common and many popular tools do not understand the label. 

Therefore, this document standardizes "X509 CRL" in order to promote 
interoperability and backwards-compatibility. Generators conforming 
to this document MUST generate "X509 CRL" labels and MUST NOT 
generate "CRL" labels. Parsers SHOULD NOT treat "CRL" as equivalent 
to "X509 CRL". 
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7.  Textual Encoding of PKCS 410 Certification Request Syntax 


PKCS 410 Certification Requests are encoded using the 
"CERTIFICATE REQUEST" label. The encoded data MUST be a BER (DER 
strongly preferred; see Appendix B) encoded ASN.1 
CertificationRequest structure as described in [RFC2986]. 


MIIBWDCCAQCCAQAwTjELMAkGA1UEBhMCUOUXJZAlBgNVBAOTHINpbW9uIEpvc2Vm 
c3NvbiBEYXRha29uc3VsdCBBQjEWMBOGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 
ByqGSM4 9AGEGBSuBBAAhAzoABLLPSkuXY0166MbxVJI3Mot 5FCFuqQfn6dTs+9/CM 
EOlSwVej77tj56kj9R/j9Q-LfysX8FO915p30GIwYAYJKOZIhvcNAQkOMVMwUTAY 
BgNVHREEETAPggilqb3NlZnNzb24ub3JnMAwGAlUdEwEB/wQCMAAwDwYDVROPAQH/ 
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQCDATAKBggqhk jOPQQDAgM/ADA8 
AhxBvfhxPFfbBbsEl1NoFmCUCzOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 
dEQc8B8jAcnuOrfU 


Figure 9: PKCS £10 Example 


The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators 
conforming to this document MUST generate "CERTIFICATE REQUEST" 
labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to 
"CERTIFICATE REQUEST". 


8. Textual Encoding of PKCS #7 Cryptographic Message Syntax 


PKCS #7 Cryptographic Message Syntax structures are encoded using the 
"PKCS7" label. The encoded data MUST be a BER-encoded ASN.1 
ContentInfo structure as described in [RFC2315]. 


MIHjBgsqhkiG9wOBCRABF6CBOzCBOAIBADFho18CAQCgGwYJKOZIhvcNAQUMMAAE 
CLfrI6drOgUWAgITiDAjBgsqhkiG9wOBCRADCTAUBggqhkiG9wODBwOIZpECRWtz 
u5kEGDCjerXY80odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9wOBBwEWMwYLKOoZI 
hvcNAQkQAw8wWJDAUBggqhkiG9wODBwQOIOtCBcUO9nxEwDAYIKwYBBQUIAOQIFAIAQ 
OsYGYUFdAHORNCIpAVbKEAQUM2XO08PMHBoYdqEcsbTodlCFAZH4- 

I END PKCS7----- 


Figure 10: PKCS #7 Example 


The label "CERTIFICATE CHAIN" has been in use to denote a degenerate 
PKCS 47 structure that contains only a list of certificates (see 
Section 9 of [RFC2315]). Several modern tools do not support this 
label. Generators MUST NOT generate the "CERTIFICATE CHAIN" label. 
Parsers SHOULD NOT treat "CERTIFICATE CHAIN" as equivalent to 

"PKES Ts 


Josefsson & Leonard Standards Track [Page 11] 


RFC 7468 PKIX Textual Encodings April 2015 


PKCS 47 is an old specification that has long been superseded by CMS 
[RFC5652]. Implementations SHOULD NOT generate PKCS #7 when CMS is 
an alternative. 


9. Textual Encoding of Cryptographic Message Syntax 


Cryptographic Message Syntax structures are encoded using the "CMS" 
label. The encoded data MUST be a BER-encoded ASN.1 ContentInfo 
structure as described in [RFC5652]. 


MIGDBgsqhkiG9wOBCRABCaBOMHICAQAwDOYLKOZIhvcNAQkQAwgwXgYJKoZIhvcN 
AQCBoFEET3icc87PKOnNK9ENqSxItVIOSa000S/ISczMslZIzkgsKk4tsQON1nUM 
dvb050Xi5XLPLEtViMwvLVLwSEOSKIFIVHAqSk3MBkkBAJvOFx0- 


Figure 11: CMS Example 


CMS is the IETF successor to PKCS #7. Section 1.1.1 of [RFC5652] 
describes the changes since PKCS 47 v1.5.  Implementations SHOULD 
generate CMS when it is an alternative, promoting interoperability 
and forwards-compatibility. 


10. One Asymmetric Key and the Textual Encoding of PKCS #8 Private Key 
Info 


Unencrypted PKCS #8 Private Key Information Syntax structures 
(PrivateKeyInfo), renamed to Asymmetric Key Packages 
(OneAsymmetricKey), are encoded using the "PRIVATE KEY" label. The 
encoded data MUST be a BER (DER preferred; see Appendix B) encoded 
ASN.1 PrivateKeyInfo structure as described in PKCS #8 [RFC5208], or 
a OneAsymmetricKey structure as described in [RFC5958]. The two are 
semantically identical and can be distinguished by version number. 


MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBGOwawIBAQOSgVCB/UNPxalR9zDYAjOIf 
jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK 
HOM6xpM2q-*53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ 


Figure 12: PKCS 48 PrivateKeyInfo (OneAsymmetricKey) Example 
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11.  Textual Encoding of PKCS 48 Encrypted Private Key Info 


Encrypted PKCS #8 Private Key Information Syntax structures 
(EncryptedPrivateKeyInfo), called the same in [RFC5958], are encoded 
using the "ENCRYPTED PRIVATE KEY" label. The encoded data MUST be a 
BER (DER preferred; see Appendix B) encoded ASN.1 
EncryptedPrivateKeyInfo structure as described in PKCS #8 [RFC5208] 
and [RFC5958]. 


MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIDb3DQEFDDAOBAghhICA6T/51QICCAAw 
FAYIKOZIhvcNAwCECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW 
ZOJIoHyRmKK/-*cr9QPLnzxImmOTR9sA4JrG3CilzTWvb0jIvbG3huO0zyFPraoMkap 
8eRzWsIvC5SVel-*CSjoS2mVS87cyjlD-*txrmrXOVYDE-*eTgMLbrLmsWh3QkCTRtFE 
QC7kONNZzUHTV9yGDwfqMbw-- 


Figure 13: PKCS #8 EncryptedPrivateKeyInfo Example 
12. Textual Encoding of Attribute Certificates 


Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATE" 
label. The encoded data MUST be a BER (DER strongly preferred; see 
Appendix B) encoded ASN.1 AttributeCertificate structure as described 
in [RFC5755]. 


MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVOQOI 
DAhOZXcgWW9yazEUMBIGA1UEBwwLUS3RvbnkgOnJvb2sxDzANBgNVBAOMBkNTRTUS5 
MjE6MDgGA1UEAwwxU2NvdHOgUG3RhbGxlci91bWFpbEFkZHJlc3M9c3NOYWxsZXJA 
aWMuc3VueXNiLmVkdQOIGARWrgUUSOIGMMIGJpIGGMIGDMOQOswCQYDVQOQOGEWJVUZER 
MA8GAl1UECAwITmV3IFlvcmsxFDASBgNVBACMCINOb255IEJyb29rMQ8wDQYDVQOK 
DAZDUOULOTIxOjJA4BGNVBAMMMVN jb3ROIFNOYWxsZXIvZWlhaWxBZGRyZXNzPXNz 
dGFsbGVyQGljLnN1bnlzYi5lZHUwDOQYJKoZIhvcNAQEFBOACBgEVq4AFFSjAiGA8z 
OTA3MDIwMTA1MDAwMFOYDzM5MTEWMTMXxMDUWwMDAwWJjArMCkGA1UYSDEiMCCGHmhO 
dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9wOBAQUFAAOBgOQAV 
M9axFPXXozEFcer06bj9MCBBCOLtAM7ZXcZjoxyva7xCBDmtZXPYUluHf5OcWPJz 
5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx-*PGlICc7zpZiGmCYLl641AEGPO/bsw 
SmluaklaZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ-- 


Figure 14: Attribute Certificate Example 
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13. Textual Encoding of Subject Public Key Info 


Public keys are encoded using the "PUBLIC KEY" label. The encoded 
data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 
SubjectPublicKeyInfo structure as described in Section 4.1.2.7 of 
[RFC5280]. 


MHYwEAYHKOZIZzjOCAQYFKAEEACIDYgAEnlLlwLN/KBYORVHO6HfIMTzfEqJOVztLe 
kLchp2hi78cCaMY81FB1Ys8J917krc+M4aBeCGYF jbathixttJWPL7yd1lE+5UG4U 
Nkn3Eos8EiZByi9DVsyfy9%eejht+8AxXgp 


Figure 15: Subject Public Key Info Example 
14. Security Considerations 


Data in this format often originates from untrusted sources, thus 
parsers must be prepared to handle unexpected data without causing 
security vulnerabilities. 


Implementers building implementations that rely on canonical 
representation or the ability to fingerprint a particular data object 
need to understand that this document does not define canonical 
encodings. The first ambiguity is introduced by permitting the text- 
encoded representation instead of the binary BER or DER encodings, 
but further ambiguities arise when multiple labels are treated as 
similar. Variations of whitespace and non-base64 alphabetic 
characters can create further ambiguities. Data encoding ambiguities 
also create opportunities for side channels. If canonical encodings 
are desired, the encoded structure must be decoded and processed into 
a canonical form (namely, DER encoding) . 
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Appendix A.  Non-conforming Examples 


This appendix contains examples for the non-recommended label 
variants described earlier in this document. As discussed earlier, 
supporting these is not required and is sometimes discouraged. 
Still, they can be useful for interoperability testing and for easy 
reference. 


MI IBHDCBxaADAgECAgIcxzAJBgcqghk jOP QQBMBAxD j AMBgNVBAMUBVBLSVghMB4X 
DTEOMDkxNDA2MTU1LMFoXDTIOMDkxNDA2MTU1MF owEDEOMAWGA1UEAxQFUEt JWCEw 
WTATBgcqhk jOPOIBBggqhk jOPOMBBwNCAATwoQSr8 63Q0rROPORIYQ96H7WykDePH 
Wa0eVAE24bth43wCNct*U5aZ76l1dhGhSSJkVWRgVH5tprLIrtnzflqt*X40xAwDjAM 
BgNVHRMBAf 8EAjJAAMAkGByqGSM4 9BAEDRWAWRAIfMdKS5F631MnWVhi7uaKJzKCs 
NnY/OKgBex 6MIEFAv2AThAI2GdvfL+mGvhyP ZE+JxRxWChmggb5 / 9eHdUcmW/ jkOH 


Figure 16: Non-standard 'X509' Certificate Example 


MI IBHDCBxaADAgECAgIcxzAJBgcghk jOP QQBMBAxD j AMBgNVBAMUBVBLSVghMB4X 
DTEOMDkxNDA2MTU1LMFoXDTIOMDkxNDA2MTU1MF owEDEOMAWGA1UEAxQFUEt JWCEw 
WTATBgcqhkjOPOIBBggqhkjOPOMBBwWNCAATwoQSr863Q0rROPORIYO96H7WykDePH 
Wa0eVAE24bth43wCNc*U5aZ761dhGhSSJkVWRgVH5tprLIrtnzflqt*X40xAwDjAM 
BgNVHRMBAf8bEAjAAMAkGByqGSMA4 9BAEDRWAWRAIfMdKS5F631MnWVhi7uaKJzKCs 
NnY/OKgBex6MIEAv2AIhAI2GdvfLt*mGvhyPZE-JxRxWChmggb5/9eHdUcmW/JjkOH 


Figure 17: Non-standard 'X.509' Certificate Example 


MIIBWDCCAQCCAQAwTjELMAkGA1UEBhMCUOUXJZzAlBgNVBAOTHINpbW9ulEpvc2Vm 
c3NvbiBEYXRha29uc3VsdCBBOjEWMBOGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 
ByqGSM4 9AgGEGBSuBBAAhAzoABLLPSkuXY0166MbxVJI3Mot 5FCFuqQfn6dTs+9/CM 
EOlSwVej77tj56kj9R/j9Q-LfysX8FO915p30GIwYAYJKOZIhvcNAQkOMVMWUTAY 
BgNVHREEETAPggi1qb3NlZnNzb24ub3JnMAwGAlUdEwEB/wQCMAAwDwYDVROPAQH/ 
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQCDATAKBggqhk jOPQQDAgM/ADA8 
AhxBvfhxPFfbBbsEl1NoFmCUCzOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 
dEQc8B8jAcnuOrfU 
Rec END NEW CERTIFICATE REQUEST----- 


Figure 18: Non-standard 'NEW' PKCS #10 Example 
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MIHjBgsqhkiG9wOBCRABF6CBOzCBOAIBADFho18CAQCgGwYJKOZIhvcNAQUMMAAE 
CLfrI6drO0gUWAgITiDAjBgsqhkiG9wOBCRADCTAUBggqhkiG9wODBwOIZpECRWtz 
u5kEGDCjerXY80odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9wOBBwEWMwYLKOoZI 
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwOI0tCBcU0 9nxEwDAY IKwYBBQUIAQIFAIAQ 
OsYGYUFdAHORNc1p4VbKEAQUM2 Xo8PMHBoYdqEcsbTod1CFAZH4= 


Figure 19: Non-standard ’CERTIFICATE CHAIN’ Example 
Appendix B. DER Expectations 


This appendix is informative. Consult the respective standards for 
the normative rules. 


DER is a restricted profile of BER [X.690]; thus, all DER encodings 
of data values are BER encodings, but just one of the BER encodings 
is the DER encoding for a data value. Canonical encoding matters 
when performing cryptographic operations; additionally, canonical 
encoding has certain efficiency advantages for parsers. There are 
three principal reasons to encode with DER: 


1. A digital signature is (supposed to be) computed over the DER 
encoding of the semantic content, so providing anything other 
than the DER encoding is senseless. (In practice, an implementer 
might choose to have an implementation parse and digest the data 
as is, but this practice amounts to guesswork.) 


2. In practice, cryptographic hashes are computed over the DER 
encoding for identification. 


3. In practice, the content is small. DER always encodes data 
values in definite-length form (where the length is stated at the 
beginning of the encoding); thus, a parser can anticipate memory 
or resource usage up front. 
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Figure 20 matches the structures in this document with the particular 
reasons for DER encoding: 


Sec. Label Reasons 
————-4- v ES ne du ue po ders d vas md umen ey + enl a eid pu Een 
5 CERTIFICATE 1 2 ^3 
6 X509 CRL ai 
7 CERTIFICATE REQUEST I "3 
8 PKCS7 * 
9 CMS x 
10 PRIVATE KEY 3 
11 ENCRYPTED PRIVATE KEY 3 
12 ATTRIBUTE CERTIFICATE 1 73 
13 PUBLIC KEY 2 3 


Figure 20: Guide for DER Encoding 


* Cryptographic Message Syntax is designed for content of any length; 
indefinite-length encoding enables one-pass processing (streaming) 
when generating the encoding. Only certain parts -- namely, signed 
and authenticated attributes -- need to be DER encoded. 

^ Although not always "small", these encoded structures should not be 

particularly "large" (e.g., more than 16 kilobytes). The parser 

ought to be informed of large things up front in any event; this is 
yet another reason to DER encode these things in the first place. 


Figure 20: Guide for DER Encoding 
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